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I. THE EXAMINER'S REJECTION OF CLAIMS 1, 2, 16, 17, 30, 31, 33, 46, 
47, AND 61-84 UNDER 35 USC 103(A) AS BEING UNPATENTABLE 
OVER AAPA IN VIEW OF LOWERY, IN FURTHER VIEW OF NAZEM ET 
AL. REPRESENTS A FIRST CLEAR ERROR. 

Claim 1 recites receiving a single request specifying multiple content components 
derived from content hosted by a plurality of distinct component servers, 
generating a plurality of requests for the content as parallel worker threads 
spawned from a main execution thread, and sending each of the plurality of 
requests to the component servers before receiving any response, thereby 
permitting concurrent generation of the content components at the component 
servers. A personalized network page is assembled and transmitted. As 
understood, no combination of AAPA, Lowery nor Nazem et al. teaches or 
suggests this feature. 

As the Examiner concedes that neither AAPA nor Lowery teach or suggest this 
feature, the following refers particularly to Nazem et al., and particularly to the 
illustration at Figure 2 and associated text descriptions at the abstract and at 
columns 2-4 in the specification of Nazem et al. 

An advantage of Applicants' invention is that the requested data is retrieved from 
each of the component servers very soon after a request is received from a 
client, for example, client 51 8A of Applicants' Figure 5. The second element of 
Applicants' claim 1 recites specifically " After receiving the single request, 
generating a plurality of information requests for the content This feature of 
Applicants' invention permits the assembly of a network page that has very fresh 
data. 

Nazem et al., on the other hand, teach to assemble a page entirely at the page 
server from data that has been previously retrieved and stored at the shared 
memory 212. This requires that the data used must be retrieved from data 
sources 230, 232, 234 some time before a client request for the web page. 

Nazem et al. clearly do not teach or suggest retrieving the data after receiving a 
request from a client, e.g., see the Background at column 1 , lines 30-47, and 
column 4, lines 9-23. For example, beginning at column 3, line 65, Nazem et al. 
state that: 

Using user templates and a shared memory for the live data, page server 
104 can quickly build custom pages in response to a user request. 
Where the user template is cached, the page can be generated entirely 
within the page server 104( emphasis added). 
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Beginning at line 10, Nazem et al. further state that: 

[t]he user will never be faced with a situation where they have to wait for a 
server to rebuild a page for them by querying the various data providing 
servers .... Page generator 210 can generate custom front page 218 
much more quickly using shared memory 212 as compared with using 
servers 230, 232, 234 and page template 202. One reason for this is 
that the time it takes to retrieve data from shared memory 212 does not 
appreciably increase relative to the bandwidth delay time when more data 
is retrieved. For example, if stock server 232 were queried for each 
individual stock quote, a page with fifty stock quotes might take ten 
times as long to generate as a page with five stock quotes. 

And at the Abstract, lines 14-17, Nazem et al. further state: 

With the live data stored in a local, shared memory, any custom page can 
be built within the page server, eliminating the need to make requests 
from other servers for portions of the live data. 

Nazem et al. teach that it is better to retrieve the data before a client request, 
then to do so after a request comes in, because this avoids untoward delays due 
to bandwidth constraints. Nazem et al. contemplate that retrieving the data after 
a request comes in for a personalized page would result in intolerable delays in a 
serial processing environment wherein the multiple content components are 
retrieved consecutively. Where Nazem et al. mention that "a page with fifty 
stock quotes might take ten times as long to generate as a page with ten stock 
quotes," they clearly suggest that the delay is equal to the sum of the retrieval 
processes for each individual content component. 

Applicants' invention advantageously requires generation of multiple requests for 
multiple content components as parallel worker threads spawned from a main 
execution thread , thereby permitting concurrent generation of the content 
components at the component servers. In this way, the data may be retrieved 
after the request comes in, thereby providing enhanced freshness, while the 
generation of multiple requests as parallel worker threads permitting concurrent 
generation of the content components does not result in a delay that is the sum 
of the time for each retrieval process. Instead, the delay will be only as long as 
the longest retrieval process for any of the requested components (note that 
Applicants' invention as set forth at claim 2 sets forth an upper limit on the wait 
time before generating the personalized page without a component that is 
delayed beyond a timeout period). The result is that Applicant's invention 
provides a personalized page with fresher data than Nazem et al., and without 
intolerable delay. As Nazem et al. neither teaches to retrieve the data from the 
component servers after a request for a personalized page, nor to generate 
multiple requests for the content components as parallel worker threads spawned 
from a main execution thread, thereby permitting concurrent generation of the 
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content components at the component servers, whereby the retrieving by parallel 
worker threads greatly reduces delays feared by Nazem et al. as intolerable in a 
serial processing environment, then Applicants' claim 1 is allowable. 

II. THE EXAMINER'S REJECTION OF CLAIMS 3, 13-15, 18, 28-30, 33, 43- 
45, 48 AND 58-60 UNDER 35 USC 103(A) AS BEING UNPATENTABLE 
OVER AAPA IN VIEW OF LOWERY, IN FURTHER VIEW OF NAZEM ET 
AL., IN FURTHER VIEW OF GREENWOOD REPRESENTS A SECOND 
CLEAR ERROR. 

First, Claim 3 is allowable as being dependent from claim 1 , i.e., for the same 
reasons set forth above with regard to the Nazem et al. reference. 

Second, Claim 3 is allowable for the following additional reason. Applicants' 
claim 3 recites "instantiating a timer ... and if no response is received from the 
first or second component server prior to a timeout period of the timer, . . . 
establishing the response from that component as a null value and carrying out 
the ... transmitting the personalized web page ... without waiting for the 
response." Greenwood does not teach or suggest this feature. Moreover, 
because Greenwood is drawn to a nonanalogous field of processing to 
Applicants' invention, it would not have been obvious to combine Greenwood 
with the other references including Nazem et al. 

Greenwood relates to a browsing process, and not a process for assembling a 
personalized page. During the browsing process of Greenwood, a download 
request may be initiated. The Greenwood method allows continued browsing 
while the download occurs and is monitored in the background. As illustrated at 
Figures 3A, 3B and 3D of Greenwood, if a download is determined to be 
temporarily delayed, then the request will be repeated, or new requests sent, 
until a maximum number of requests have been sent at 342 and 380 of Figures 
3B and 3D, respectively, at which time the process is ended respectively at 344 
and 382. Thus, Greenwood stops sending requests when a maximum number of 
request have been sent, and not after a specified timeout period, as set forth at 
Applicants' claim 3. Moreover, Greenwood simply does not teach transmission 
of a personalized web page without waiting for a response from one of the 
component servers after a timeout period, as set forth at Applicants' claim 3. 
With the latter point, Greenwood simply stops requested the download. 
Notwithstanding these distinctions between Applicants' invention and 
Greenwood, there is a fundamental difference between downloading a URL by 
clicking a link within a browser window in accordance with Greenwood, and 
receiving a personalized web page with multiple content components retrieved 
from multiple component servers in accordance with Applicants' invention. 

III. APPLICANTS RESPECTFULLY SUBMIT THAT EACH OF CLAIMS 4- 
12, 19-27, 34-42 and 49-57 ARE ALLOWABLE FOR THE SAME 
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REASONS AS PREVIOUSLY DESCRIBED WITH RESPECT TO NAZEM 
ET AL. AND GREENWOOD. THUS, THIS REJECTION REPRESENTS 
A THIRD CLEAR ERROR. 
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